The flow suggested in this PR (i.e. calling validate() through Grid object) does not make sense to me because we are already creating any Grid, representing in the UGRID conventions, regardless of the original grid type coming from the file. In other words, any dataset that does not conform to UGRID standards would lead our code to throw exceptions in the Grid creation stage, wouldn't it?

I'd assume a flow instead like: ux.validate(xr.open_dataset(file)) (This would require us to modify the draft UXarray API, too)

Am I missing anything here?

This is more for when the file is corrupt or the vertices or connectivity matrix that initialize the mesh are invalid and somehow passes the reader phase.

Eg. https://github.com/UXARRAY/uxarray/pull/173/files#diff-5c959492b91b5fdfc565d14eb2f672cf27b2f9722860c7efdba6a2109eb618a6R202

Test failures seem to come from reliance on this ftp mesh file unavailability:
https://web.lcrc.anl.gov/public/e3sm/inputdata/share/meshes/mpas/ocean/oQU480.230422.nc
am I missing something @philipc2 ?

Test failures seem to come from reliance on this ftp mesh file unavailability: https://web.lcrc.anl.gov/public/e3sm/inputdata/share/meshes/mpas/ocean/oQU480.230422.nc am I missing something @philipc2 ?

This is correct. See #582